Week Overview
Mon – Fri · 10 hours total
The two services that let machines find each other by name
Every other service in this course — the web server in Week 4, the VPN in Week 5, the Docker containers in Week 6 — depends on machines being able to find each other. IP addresses work, but they are hard to remember and hard to maintain at scale. DHCP and DNS solve those two problems: DHCP assigns addresses automatically, and DNS resolves names to addresses so humans don't have to track IPs.
Week 3 builds both services on S1. Days 1–2 cover DHCP using isc-dhcp-server — scope configuration, DHCP-specific logging via rsyslog, client verification, and reservations. Days 3–4 cover BIND9 DNS — the config file hierarchy, forward and reverse zones, named-checkzone validation, secondary DNS on S2 with zone transfer. The DNS zones built this week are used directly in Week 4 (Nginx virtual host) and Week 5 (VPN). Day 5 is assessment.
A thread from Week 2 ties in here: the /etc/hosts entry for loghost that students added on S2 in Lab 2D gets replaced with a proper DNS A record today. DNS makes that temporary workaround unnecessary.
Week at a glance
Monday
DHCP Server Setup
Install isc-dhcp-server, configure interfaces and dhcpd.conf, DHCP-specific logging via rsyslog, verify S2 gets a lease (Lab 3A)
Tuesday
DHCP Troubleshooting & Reservations
Deliberate config errors, lease database, MAC-based reservations, DORA process deep-dive (Lab 3B)
Wednesday
BIND9 Install & Forward Zone
BIND9 config hierarchy, named.conf.options, named.conf.local, zone file syntax, SOA/NS/A records, named-checkzone (Lab 3C)
Thursday
Reverse Zone, Secondary DNS & dig
PTR records, reverse zone, zone transfer to S2, restrict allow-transfer, dig interrogation (Lab 3D)
Friday
Mini-Assessment 3
Written: DHCP/DNS concepts. Practical: build a working zone from a spec.
Learning Outcomes
By end of Week 3, students can…
Configure isc-dhcp-serverSet the listening interface, write a dhcpd.conf scope with lease times, gateway, and DNS options, and verify with a client lease
Direct DHCP events to a custom log fileUse the log-facility directive and rsyslog rules to route DHCP events out of syslog and into a dedicated dhcpd.log
Create a MAC-based DHCP reservationUse a host block in dhcpd.conf to assign a fixed address to S2 based on its MAC address
Explain the BIND9 config file hierarchyDescribe the role of named.conf, named.conf.options, named.conf.local, and named.conf.default-zones
Build a BIND9 forward zoneWrite a zone declaration in named.conf.local, create a zone database file with SOA, NS, A, and CNAME records, and validate with named-checkzone
Build a reverse lookup zoneWrite a zone declaration using the in-addr.arpa format and populate it with PTR records
Configure a secondary DNS serverDefine a type secondary zone on S2 pointing at S1 as the primary, verify zone transfer, and restrict transfers to authorised servers only
Use dig for DNS interrogationQuery a specific server, request all record types, and interpret the output sections (QUESTION, ANSWER, AUTHORITY, ADDITIONAL)
Monday
Lecture + Lab 3A · 2 hrs
DHCP protocol, isc-dhcp-server install and scope configuration, DHCP logging
0:00–0:30
Lecture
0:30–1:50
Lab 3A
1:50–2:00
Debrief
- Lecture (30 min): The DORA process — Discover, Offer, Request, Acknowledge. How a client with no IP finds a DHCP server using broadcast. The lease concept — temporary assignment with renewal and rebinding timers. dhcpd.conf structure: global options, subnet declarations, range, option routers, option domain-name-servers, lease times. Why DHCP must be restricted to internal interfaces only — broadcasting on the external NIC would hand out addresses to the classroom network.
- Lab 3A (80 min): Install isc-dhcp-server. It fails to start by default — identify why (no interface configured). Edit
/etc/default/isc-dhcp-server to bind to eth1. Rename the default dhcpd.conf and write a clean one. Configure a scope for 192.168.50.0/24, add DHCP-specific logging via rsyslog (local0 facility to dhcpd.log), restart, verify S2 gets a lease. Read the lease file.
- Debrief (10 min): Walk through a DORA exchange using tcpdump. Ask: "Why does DHCP use broadcast rather than unicast for the initial Discover?" — the client has no IP yet and doesn't know the server's address. Preview Tuesday: deliberate errors, the lease database, and reservations.
Instructor note: The initial failure to start is intentional and educational — isc-dhcp-server requires an interface to be configured before it will run. Students who simply check systemctl status and see "failed" without reading the error message will be stuck. Train them to read the journal output carefully.
Tuesday
Lab 3B · 2 hrs
Deliberate errors, lease database, MAC reservations, DORA tcpdump capture
0:00–0:10
Recap
0:10–1:50
Lab 3B
1:50–2:00
Debrief
- Recap (10 min): Ask: "What are the four steps of the DORA process, and which ones use broadcast vs. unicast?" Verify all students have a working DHCP lease on S2. Anyone who doesn't — address the issue now.
- Lab 3B (100 min): Introduce deliberate errors one at a time (missing semicolons, invalid range, missing subnet line) — read the syslog/dhcpd.log output after each to identify what the error message says. Create a MAC-based reservation for S2. Reconfigure S2 to use DHCP (change Netplan from static to DHCP), request a new lease, and verify S2 gets its reserved address. Capture the full DORA exchange with tcpdump on S1 (
sudo tcpdump -i eth1 -n port 67 or port 68). Identify each packet type in the capture.
- Debrief (10 min): Walk through the tcpdump capture together. The Discover and Request are broadcast (destination 255.255.255.255). The Offer and ACK are unicast from the server. Ask: "What two issues could arise if you had two DHCP servers on the same segment?" — race condition for Offers, potential IP conflicts if they serve overlapping ranges. Preview Wednesday: DNS.
Note: Before the end of Tuesday, restore S2's Netplan config back to a static IP. The DNS labs need a predictable S2 address. Students who leave S2 on DHCP will have issues when writing zone records in Lab 3C.
Wednesday
Lecture + Lab 3C · 2 hrs
DNS hierarchy, BIND9 config files, forward zone, SOA/NS/A records, named-checkzone
0:00–0:10
Recap
0:10–0:40
Lecture
0:40–1:50
Lab 3C
1:50–2:00
Debrief
- Recap (10 min): Ask: "Right now, when you type a hostname into a command on S2 — how does it resolve?" Students should know it uses the DNS servers configured in Netplan (currently the classroom DNS). Today we build our own DNS server so that internal hostnames resolve without touching the classroom infrastructure.
- Lecture (30 min): DNS hierarchy — root servers, TLDs, authoritative servers, recursive resolvers. The BIND9 config file hierarchy: named.conf includes three files; named.conf.options (daemon settings, forwarders, allow-query); named.conf.local (our zone definitions); named.conf.default-zones (localhost, root hints). Zone file anatomy:
$TTL, SOA record fields (serial convention, refresh/retry/expire/minimum), NS records, A records. The trailing dot rule — why forgetting the dot causes a zone to double-append the domain. named-checkzone and named-checkconf as validation tools before restarting. The deprecated type master vs the current type primary.
- Lab 3C (70 min): Install BIND9 on S1 and S2. Configure named.conf.options to allow queries from lab networks. Add zone declaration to named.conf.local (using the student's name as the domain). Create the zone database file with SOA, NS, A records for s1, s2, s3, and loghost. Validate with named-checkzone. Verify with nslookup and dig. Add CNAME record for www. Update systemd-resolved to use S1 as the DNS server.
Instructor note: The trailing dot rule is the most common source of zone file errors. Write a concrete example on the board: if the zone is yourname.net and you write s1 A 192.168.50.1, BIND resolves it to s1.yourname.net. If you write s1. A 192.168.50.1 (with dot), BIND treats it as an absolute name s1. (just "s1", a root-level name) — almost never what you want. If you write s1.yourname.net. (FQDN with trailing dot), it stays as-is. Spend two minutes on this before students start the lab.
Thursday
Lab 3D · 2 hrs
Reverse lookup zone, secondary DNS on S2, zone transfer, allow-transfer, dig
0:00–0:10
Recap
0:10–1:45
Lab 3D
1:45–1:55
Bonus
1:55–2:00
Wrap
- Recap (10 min): Quick check — can students resolve s1.yourname.net from S2? Ask: "What does a reverse lookup do and why would you need it?" — maps IP to hostname. Useful for logging (readable hostnames instead of IPs), email server validation (PTR records are checked by spam filters), and security tools. Preview the in-addr.arpa notation for reverse zones.
- Lab 3D (95 min): Add a reverse lookup zone declaration to named.conf.local using in-addr.arpa format. Create the reverse zone database file with PTR records for s1, s2, s3. Verify with
nslookup and dig -x. Configure S2 as a secondary DNS server — add zone declaration with type secondary and primaries { S1-IP; }. Verify zone transfer in BIND9 logs. Restrict zone transfers on S1 to S2 only using allow-transfer. Use dig to interrogate the zone and test the AXFR restriction. Remove the /etc/hosts loghost entry from Lab 2D and verify it resolves via DNS instead.
- Bonus (10 min): Use dig to perform a zone transfer of a real permissive zone on the internet (zonetransfer.me). Read the output structure. Discuss why allowing public AXFR is a security risk — it hands an attacker a complete map of the internal network.
- Wrap (5 min): The DNS zones built today are the foundation for everything that follows. Week 4's Nginx virtual host config uses the zone name. Week 5's VPN lab uses hostnames. Remind students to verify their zones are working before Monday.
⭐ Thursday Bonus — dig zone transfer
- From S1:
dig @nsztm1.digi.ninja zonetransfer.me AXFR
- Read the output — A records, MX records, TXT records, SRV records
- Ask: "What could an attacker learn from a successful AXFR of an internal zone?" — all server names, all IPs, all mail servers, any internal service hints in TXT/SRV records
- Compare to what
dig @S1-IP yourname.net AXFR now returns after adding allow-transfer — should be refused
Friday
Mini-Assessment 3 · 2 hrs
Written (30%) + Practical: build a working zone from spec (70%)
0:00–0:30
Written
0:30–1:45
Practical
1:45–2:00
Review + Preview W5
- Written (30 min): DORA process, dhcpd.conf syntax, DHCP lease database location, DNS record types (A, AAAA, CNAME, MX, NS, PTR, SOA), zone file trailing dot rule, named-checkzone command, primary vs secondary zone distinction.
- Practical (75 min): Students are given a fresh set of requirements and must build a complete DNS zone from scratch — forward zone, reverse zone, and secondary server — within the time limit. All records are verified with dig and nslookup by the instructor.
- Review + Week 4 Preview (15 min): Common mistakes: serial number not incremented, missing trailing dots on FQDNs, wrong in-addr.arpa notation for reverse zones. Preview Week 4: Nginx web server, SSL/TLS configuration, and the log-driven troubleshooting module. The DNS zone built this week will provide the hostname the virtual host config resolves to.
Mini-Assessment 3 — Topic Coverage
| Topic | Weight | Source |
|---|
| DORA process — steps, broadcast vs unicast, each packet's purpose | 10% | Monday lecture + Lab 3A |
| dhcpd.conf syntax — scope, range, options, lease times, reservations | 15% | Labs 3A/3B |
| DHCP logging via rsyslog local0 facility | 5% | Lab 3A |
| DNS record types — A, PTR, NS, SOA, CNAME, MX | 15% | Wednesday lecture |
| Zone file syntax — TTL, trailing dot rule, serial format | 15% | Lab 3C |
| named-checkzone and named-checkconf usage | 5% | Lab 3C |
| Secondary DNS — zone declaration, zone transfer, allow-transfer | 15% | Lab 3D |
| Practical zone build | 20% | All week |
What you need ready before Monday
All three VMs running with NTP and SSH working from Week 2
Lab 3A, 3B, 3C, 3D handouts printed
Week 2 rsyslog/logrotate changes reverted (snapshot restored)
S2 static IP confirmed (192.168.50.2)
Mini-Assessment 3 printed (Friday)
Student name to use as domain name confirmed (e.g. smith.net)